Extreme Programming

All + All -

Extreme Programming

+ - Kannusta muutokseen
- Luentojen lähde: Kent Beck "eXtreme Programming Explained - Embrace Change", Addison-Wesley, 2000
  Vanha väite:
  Muutos projektin loppupuolella maksaa eksponentiaalisesti
  enemmän kuin muutos projektin alkupuolella.
  Uusi väite: Tehdään asiat niin, ettei vanha väite pidä paikkaansa.
  Kuin autolla ajamista: pieniä korjausliikkeitä.
  + - Sopii, jos
  - vaatimukset muuttuvat
  - uusi alue, korkea riski
  - pieni ryhmä
  Vaatii läheistä, kommunikoivaa työskentelyä ja testausta
  Antaa tuotteliaan ryhmän, tarvitun ohjelmiston tarpeeseen.
+ - 1. Arvot
- + - Kommunikaatio
  - Osa XP:n periaatteista velvoittaa kommunikoimaan
- + - Yksinkertaisuus
  - (Kansanomaisuus, koruttomuus)
    Mikä on yksinkertaisin toimiva ratkaisu?
    Erittäin hankalaa
    XP veto: On parempi tehdä yksinkertaista tänään ja maksaa huomenna vähän enemmän siitä, että joutuu huomenna muokkaamaan ratkaisua, kuin että tekee tänään monimutkaisen ratkaisun, jota ei kuitenkaan tarvita.
- + - Palaute
  - "Älä kysy minulta, kysy järjestelmältä."
  - "Oletko jo kirjoittanut testitapauksen?"
  - aikaskaala
    - + - minuutit, päivät
      - testit
      - käyttäjäkertomukset
    - + - viikot, kuukaudet
      - toiminnallisuustestit
      - asiakkaan aikatauluarviointi
      - + - aikainen julkaisu
        asiakas saa käsinkosketeltavan kuvan ohjelmistosta
        
        kehittäjät saavat konkreettista palautetta
  - yhteys
    - kommunikaatio lisääntyy
    - yksinkertaisuus näkyy helposti testattavassa systeemissä, jota on myös helpompi arvioida
- + - Rohkeus
  - + - Täysillä eteenpäin edellisten arvojen valossa, ...
    - ... muuten joku muu tekee sen.
  - Tehdään ne vaikeat päätökset, eikä kierretä.
  - + - Huono ja tarpeeton koodi tulee heittää pois.
    - Jos jokin ratkaisu on ongelmallinen, on parempi aloittaa puhtaalta pöydältä.
  - Rohkeus taistella monimutkaisuutta vastaan.
  - + - Jos muut arvot eivät ole kohdallaan, johtaa rohkeus vain roskakoodaukseen.
    - Asian sivusta:
      - + - hacking
        hyvä asia
        
        ihmiset osaavia ja innostuneita
        
        hacker
        
        cracker ei tee tätä
      - + - roskakoodaus
        ihmiset ovat osaavinaan, mutteivät oikeasti osaa mitään
        
        ad hoc koodaus
        
        vastuuntunnotonta räpellystä
        
        "hacking" termin väärinkäyttöä
      - + - cracking
        suojattujen resurssien suojauksen murtamista
        
        resurssien luvatonta käyttöä
        
        usein myös osaavaa, taito palvelee väärää asiaa
        
        skript kiddies
        
        cracker
        
        hacker ei tee tätä!
+ - 2. Periaatteet
- + - Perustavat
  - nopea palaute
  - pyrkimys yksinkertaisuuteen
  - inkrementaalinen muutos
  - muutoksen arvostus
  - laadukas työ
- + - Lisät
  - opeta oppimista
  - pieni alkusijoitus
  - pelaa voittaaksesi
  - konkreetit kokeilut
  - avoin, rehellinen kommunikointi
  - toimi vaiston mukaan, älä vastaan
  - hyväksytty vastuu
  - paikallinen mukauttaminen
  - + - kevyt matkalaukku
    - vähän yksinkertaisia arvokkaita tavaroita
  - + - rehti mitta
    - Kyllä: ...tekemiseen mennee noin kaksi viikkoa.
    - EI: ...tekemiseen menee 14.176 tuntia.
+ - 3. Käytännöt
- + - Suunnittelupeli
  - Liiketoiminta
    - Vaikutusalue, pelivara
    - Prioriteetit
    - Julkaisun koostumus
    - Julkaisun päivämäärä
  - Kehitys
    - Kehitysaika-arvio
    - Seuraukset
    - Prosessi
    - Yksityiskohtainen aikataulutus
- + - Pienet julkaisut
  - arvokkaimmat liiketoimintavaatimukset täytetty
  - + - lyhyet julkaisuvälit, helpompi suunnitella
    - pitkä suunnitelma silti, muttei niin tarkasti, ranskalaiset viivat riittää
- + - Metafora
  - 'naiivi'
  - sovellusalueen kieli
  - asiakkaan kieli
  - + - arkkitehtuuri, jonka voi näyttää
    - asiakkaalle
    - bisneshenkilöille
- + - Selkeän yksinkertainen suunnitelma
  - kaikki testit toimii
  - ei logiikan toistoa
  - ilmaisee tärkeät aikeet ohjelmoijille
  - minimoitu määrä luokkia ja metodeja
- + - Testaus
  - ensin testi, sitten koodi
  - toki voi kokeilla koodia, mutta sitten kokeilut roskiin ja testejä kirjoittamaan
  - + - hyvä testausympäristö, joka tukee tällaista testausta
    - JUnit
    - PyUnit
    - ???Unit
    - + - IDE:t
      - Eclipse
      - muutkin
- + - Uudelleentyöstö (refactoring)
  - Kun koodi on huonosti tehty tai suunniteltu, tehdään se uusiksi.
  - Roskat roskiin.
  - + - Työkalutuki
    - Eclipse
    - Kaikki muutkin IDE:t
- + - Pariohjelmointi
  - Kaksi roolia
    - + - Toteuttaja
      - toteuttaa ratkaisun parhaalla mahdollisella tavalla
    - + - Varmentaja
      - sopiiko lähestymistapa ongelman ratkaisuun
      - onko testejä, jotka eivä mahdollisesti menisi läpi
      - onko mahdollista yksinkertaistaa järjestelmää niin, että nykyinen ongelma poistuisi
  - + - dynaamista
    - jos toinen hairahtuu polulta, ottaa toinen hänen roolinsa
    - parit vaihtuvat jopa päivän aikana
  - + - epäilijöille:
    - kuinka monta kertaa olet pyytänyt apua ohjelmointiongelmaan
    - pariohjelmointi ei sovi kaikille, eivätkä kaikki sovi pariohjelmointiin
- + - Yhteinen omistajuus
  - Jokainen, joka näkee mahdollisuuden parantaa koodia, on velvoitettu tekemään parantamisen.
  - + - eri asia kuin "ei omistajuutta", ...
    - ... joka johtaa koodin rämettymiseen, kaaokseen
    - ... jossa koodi kasvaa nopeasti, mutta ryteiköksi
  - + - "ei omistajuutta" koetettiin korjata yksilöomistuksella
    - jäykkää
    - ymmärrys ei leviä
    - koodi ei juuri kehity
  - + - yhteisomistus
    - parempi yleiskuva koodista kaikilla
    - muutoksen voi tehdä heti tarvitessa, eikä pyytelyjen, anelujen ja aikataulumuutosten jälkeen
    - koodi kehittyy nopeasti
    - vastuu, mutta myös me-henki
- + - Jatkuva integrointi
  - + - Esimerkiksi yksi tietokone vain integrointia varten.
    - Kun tietokone on vapaana, menee pari integroimaan oman valmiin tuotoksen.
    - + - 100% Toimivuus:
      - Tietokoneelle tultaessa siinä oleva ohjelmistoversio toimii täysin.
      - Tietokoneelta lähdettäessä siinä oleva ohjelmistoversio toimii täysin.
      - + - Seuraus: Jos ohjelmisto ei toimi, on vika meissä.
        Koodi joko korjataan, ...
        
        ... tai jos korjauksiin ei pystytä, heitetään menemään.
  - Selvästi vaatii muita käytäntöjä ja työkalutukea (unit test) toimiakseen.
- + - 40h työviikko
  - Ylitöitä ei saa tehdä kahta viikkoa peräkkäin.
  - Viikonloput ovat lepäämistä varten.
  - Jos 40h työviikkoon ei pystytä, on projektissa jotain pahasti vialla.
  - + - Vertaa myös:
    - Jenkkien loma muutaman päivän ryppäissä, ...
    - ... Euroopassa neljäkin viikkoa putkeen.
- + - Asiakas paikanpäällä
  - + - Oikea asiakas istuu ja työskentelee ryhmän parissa.
    - Kun vastaus tarvitaan, se tarvitaan heti.
    - Ja vastaus tarvitaan oikealta asiakkaalta.
    + - Vaikeimpia käytäntöjä hyväksyä, ...
    - Jos yhden asiakkaan työpanos työpaikallaan on tärkeämpää,
      kannattaako ohjelmistoa edes tehdä?
    - Asiakas voi silti tehdä myös omia töitään, jos se on vain mahdollista.
    Valitettavasti jos projekti ei toteudu, on yhden asiakkaan työpanos "mennyt hukkaan".
    XP:ssä pyritään juuri varmistamaan, ettei näin kävisi.
- + - Koodausohjeet
  - Jos ei näitä ole, on koodin yhteisomistus perin hankalaa.
  - Parantavat koodin ymmärtämistä, kun aika ei mene toiseen tyyliin totutteluun.
  - + - Ohjeiden tuettava koodin yksinkertaisuutta, selkeyttä, ja "kerran ainoastaan" suositusta.
    - Ei duplikaattikoodia.
  - + - Projektin jäsenet hyväksyvät koodausohjeet vapaaehtoisesti.
    - Toisaalta, kannattaa katsoa peiliin, jos toisenlainen kuin
      oman tyylin mukaisesti kirjoittaminen tuntuu mahdottomalta.
      Tyhmyyksiin ei silti kannata suostua: Vältä "unkarilaista" notaatiota.
      Työkalut auttavat koodausohjeen toteuttamisessa.
  - Koodin kommentointi kuten varoitusmerkit tiellä. Javadoc eri asia.
+ - 4. Strategia
- + - Johto (Management)
  - Periaatteet
  - Metriikat
  - Valmentaminen
  - Seuraaminen
  - Väliintulo
- + - Toimitilat (Facilities)
  - + - Avotila
    - Parityöskentely
    - Suunnittelualue
    - Yksityisalueita
    - Leponurkkaus
  - + - Joskus sisustussuunnittelijat saattaa suuttua.
    - Kumpi on tärkeämpää, toimiva ohjelmistokehitys...
    - ...vai sisustajan urakehitys?
  - Kokeile, testaa, niin löydät toimivan tilaratkaisun.
- + - Liiketoiminnallisen ja teknisen vastuun jako
  - B-A-L-A-N-C-Balance!
  - + - Omituisuuksiako?
    - + - Liiketoiminta päättää teknologian...
      - ...kehityksen laskelmien mukaan.
    - + - Kehitys hinnoittelee ominaisuudet...
      - ...eli kertoo toteuttamiseen tarvittavat resurssit,
        jotta liiketoiminta pystyy valitsemaan toteutettavat
        resurssit ja aikatauluttamaan toteutuksen.
  - + - Toiminta
    - + - Liiketoiminta
      - Julkaisujen vaikutusalue ja ajoitus.
      - Ominaisuuksien suhteellinen tärkeysjärjestys.
      - Ominaisuuksien vaikutusalue.
    - + - Kehitys
      - Arvio ominaisuuden toteuttamiseen kuluvasta ajasta.
      - Arvio teknisten vaihtoehtojen vaikutuksista.
      - Kehitysprosessi, joka sopii ryhmän persoonille, liiketoimintaympäristölle ja yrityskulttuurille.
      - Millä käytännöillä aloitetaan, miten käytäntöjen sopivuutta mitataan ja miten käytäntöjä muokataan.
- + - Suunnittelu (Planning)
  - + - Tarkoitus
    - Ryhmä kasaan
    - Sovitaan vaikutusalue ja prioriteetit.
    - Arvioidaan kulut ja aikataulu.
    - Luottamusta jokaiselle, että järjestelmä todella voidaan toteuttaa.
    - Perusta palautteelle. "benchmark for feedback"
  - + - Suunnittelupeli
    - Päämäärä
    - Strategia
    - + - Pelinappulat
      - Tarinakortit
        vrt. vaatimukset, käyttötapaukset
    - + - Pelaajat
      - Liiketoiminta
      - Kehitys
    - + - Pelivaiheet
      - Tutkimus (Löytöretkeily)
      - Sitoutuminen
      - Ohjaus
  - + - Iteraatioiden suunnittelu
    - Kuten suunnittelupeli
    - Vaiheet
      - Tutkimus
      - Sitoutuminen
      - Ohjaus
  - Suunnitelmat viikossa
- + - Kehitys (Development)
  - Jatkuva integrointi
  - Koodin yhteisomistus
  - Pariohjelmointi
- + - Suunnittelu (Design) Sommittelu?
  - Yksinkertaisin mikä toimii
  - "Et tule tarvitsemaan sitä."
  - "Kerran, ja vain kerran."
- + - Testaus (Testing)
  - + - Testejä kirjoittavat kehittäjät.
    - 100% toimivuus.
    - testit ensin, sitten koodi
    - jos joku testi ei mene läpi, on vian korjaaminen aloitettava välittömästi
  - + - Testejä kirjoittavat asiakkaat.
    - + - Toiminnallisuustestit.
      - Ei 100% sääntöä...
      - ...mutta kattavasti kuitenkin.
    - + - Jos asiakas ei osaa kirjoittaa testejä:
      - Jokaisessa XP ryhmässä on aina yksi määrätty testaaja.
        Määrätty testaaja ei keskity vaan vikojen etsintään,
        vaan toivoo myös parasta ja toimii kuten muukin ryhmä.
        Tavoitteena testaajalla oppia kirjoittamaan parempia ja parempia testejä.
  - + - vertaa
    - käyttötapaukset
    - "Design by contract"
    - esi- ja jälkiehdot (formaalit menetelmät)
    - invarianssi (form.men.)
+ - 5. XP projektin elinkaari
- + - Tutustuminen ja kokeilu
  - Asiakas opettelee tarinoimaan.
  - + - Kehittäjät
    - kokeilevat eri tekniikoita
    - luovat pari-kolme testitoteutusta
    - opettelevat arvioimaan työmääriä ja -aikoja (TÄRKEÄ!).
  - Työkaluihin tutustuminen
  - muutamasta viikosta muutamaan kuukauteen
- + - Suunnittelu (Planning)
  - suunnittelupeli 1-2 pv
  - ensimmäinen julkaisu 2-6 kk
- + - Itereroiden ensimmäiseen julkaisuun
  - iteraation kesto 1-4 vk
  - tuloksena (myös) funktionaaliset testit tarinoille
  - ensimmäisen iteraation tuloksena arkkitehtuuri
  - seuranta
- + - Tuotteistus
  - tiheämmät syklit
  - + - suorituskyvyn säätö
    - 1. toteuta toimivaksi
    - 2. toteuta oikein
    - 3. toteuta tehokkaasti
  - lisäideat listaan
  - juhlat lopussa, moni projekti ei pääse ikinä tänne asti
- + - Ylläpito
  - seestyminen
  - + - ihmisten vaihtuminen
    - uudet sisään
    - vanhat eteenpäin
    - vuodessa vaikka koko henkilöstö
  - help desk, kaikki osallistuu
  - uutuudet varpaisillaan
- + - Kuolema
  - asiakas ei keksi enää tarinoita
  - järjestelmäkuvaus 5-10 sivua
  - normaalia ohjelman elinkaaressa
  - tylsä versio: sovellus ei enää sovellu
  - + - koko historian kattavat juhlat
    - mitä tehtiin oikein
    - mitä tehtiin väärin
    - mitä kaikesta opittiin
+ - 6. Roolit
- + - Ohjelmoija
  - Tärkeää! Ohjelmoida niin, että ohjelmisto kommunikoi muiden ryhmän jäsenten kanssa.
  - Ohjelmakoodia ei kirjoiteta tietokoneelle, vaan toisille ihmisille!
  - Ohjelmoija ei yleensä koskaan ole asiakas. (Suunnittelupeli)
- + - Asiakas
  - ohjelmoija tietää miten ohjelmoidaan, asiakas mitä ohjelmoidaan
  - tarinoiden kirjoitus
  - päätöksenteko, mikä tärkeää, mikä ei
  - käyttäjä
  - toiminnalliset testit
- + - Testaaja
  - auttaa asiakasta
  - ajaa testit
  - toimii ryhmän mukana, ei "vastaan"
  - löydyttävä ainakin yksi
- + - Seuraaja
  - ryhmän omatunto
  - + - arviointi
    - harjoittelu
    - palaute
  - yleiskuvan saavuttaminen
  - historiatiedot
  - hienovaraisesti
- + - Valmentaja
  - kokonaiskuvan haltija
  - XP:n hyvä ymmärrys
  - välillinen vaikutus
  - merkitys suunnanvihjaajana vähenee ryhmän "aikuistuessa"
- + - Konsultti
  - yleensä ei tarvita
  - jos tarvitaan, ei tekijänä, vaan opettajana
  - paljon kysymyksiä kehittäjiltä vastattavaksi
  - konsultin tekeleet heitetään menemään ja tehdään omat
  - + - "Opeta ratkaisemaan ongelmat, äläkä ratkaise niitä asiakkaan puolesta!"
    - konsulttibiznezz saattaa kuolla tällaisiin neuvoihin :)
- + - Iso Pomo
  - rohkea, luotettava ja tarvittaessa vaativa
  - ryhmä vaatii huomioimaan tilanteen ajoittain
  - ryhmä tulee antamaan painavaa kritiikkiä päätösten vaikutuksesta
  - rehellinen kommunikointi, ryhmä kertoo heti, kun asiat eivät toimi
  - ryhmä pitää ajantasalla, eikä anna pomon yllättyä
  - rohkeutta, sillä ryhmä tekee joskus villejäkin ratkaisuja
  - jos ne toimii, voit olla onnellinen, jos ei, silloin sinua tarvitaan
  - pomo on pomo syystä
  - muuten lienee parempi, että pysyt taustalla
+ - 7. Koska XP ei toimi
- (liiketoiminta)kulttuuri
- asiakas vaatii jäykkää prosessia
- + - "sitoutuminen yritykseen"
  - XP ei onnistu väsyneenä
- + - ryhmän koko >20
  - 80 hengen XP projekti on toteutettu
- + - sisäsyntyisesti monimutkainen projekti
  - liikaa vanhoja sovelluksia muutettavaksi
- hidas käännösvaihe
- hidas tai kallis testaus
- + - väärä fyysinen ympäristö
  - hajautetut projektit?
  - kahden kerroksen väkeä
+ - 8. CMM XP:lle? Eikö mikään ole enää pyhää...
- Taso 1: Toteuta XP tarkasti kuten määritelty kerran tai pari.
- Taso 2: Mukauta XP omiin oloihisi.
- Taso 3: Ei ole väliä enää, onko XP vai ei. Homma hoituu.
- (Lähde: Kent Beck)
http://www.extremeprogramming.org/